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SMS-BASED MOBILE LOTTERY GAMES 

[001] A portion of the disclosure of this patent document contains material that 

is subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or patent disclosure as it appears in the 
Patent and Trademark Office patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

Background 

[002] Users may operate cellular telephones for numerous purposes. For 

example, users may contact one another, play games, access the internet, etc. 
Messaging and file upload and download between the user and a system and between 
numerous users is commonly found. The internet is one network that allows these 
activities. However, to use the internet as the conduit via which to perform these 
activities is costly. To reduce cost, many cellular telephones use Short Message 
Service (SMS) text messaging, such as that described in Simon Buckingham, What is 
SMS?, http://www.gsmworld.com/technology/sms/intro.shtml (2000), rather than the 
internet. Indeed, in many countries, the cellular telephones that provide for SMS text 
messaging far outnumber the cellular telephones that provide internet service. 
Consequently, to reduce cost, and to provide accessibility to as many cellular telephone 
users as possible, there is a great desirability to provide a way to use SMS text 
messaging for mobile applications wherever possible. 

[003] Gaming systems are in widespread use and continue to grow in 

popularity. For example, the use of point-of-sale terminals has expanded from 
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traditional retail environments to a wide variety of non-traditional environments. Indeed, 
in some markets consumers can purchase lottery tickets via the internet from the 
comfort of their own home. 

Brief Description of the Drawings 

[004] Fig. 1a is a flowchart that illustrates an example procedure in which lottery 

game data may be sent to an application server, according to an example embodiment 
of the present invention. 

[005] Fig. 1 b is a flowchart that illustrates an example procedure in which lottery 

game data may be sent to a remote terminal, according to an embodiment of the 
present invention. 

[006] Fig. 2 is a block diagram that illustrates the components of an example 

wireless network, according to an example embodiment of the present invention. 

[007] Fig. 3 is a flowchart that illustrates an example procedure in which players 

may collaborate to play a lottery game, according to an example embodiment of the 
present invention. 

Detailed Description of Example Embodiments 

[008] SMS text messaging support for mobile lottery game systems, where a 

user may purchase, via a cellular telephone or any remote terminal of a wireless 
network, an electronic lottery ticket for a future drawing or other lottery games, such as 
instant win games, e.g., simulated scratch-off games; highly graphical user interactive 
games; and any other kind of lottery game, is not provided. Accordingly, there is a need 
in the art for SMS text messaging support for mobile lottery games in a wireless 
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network. 

[009] Embodiments of the present invention generally relate to mobile lottery 

games. More particularly, embodiments relate to the use of Short Message Service 
(SMS) text messaging to transmit data relating to lottery games over a wireless network. 

[010] To reduce cost and also to make mobile lottery games available to a 

multitude of cellular telephone users whose cellular telephones provide support for SMS 
text messaging, but not for internet, embodiments of the present invention provide for 
lottery games data to be transmitted over a wireless network as SMS text messages. A 
gaming SMS text message is an SMS text message representation of lottery game 
data. Lottery game data is data of a lottery game provider system, such as a lottery 
game request, the actual lottery game, or other lottery game data as will be described. 

[011] Figs. 1a and 1b are flowcharts that illustrate an example procedure in 

which a user may obtain a lottery game from a data center, according to an example 
embodiment of the present invention. In Fig. 1a, a remote terminal receives player input 
data in 1 . The data may include, for example, a lottery game request. The data may 
identify the particular game a player desires, for example a lottery ticket, in particular an 
electronic representation of a lottery ticket. The data may include, for example, a series 
of numbers for a lottery ticket drawing, and/or the date of the drawing in which the user 
wishes to enter. Other data may include player or phone identification data, security 
information or codes, geographic information, etc. The request may be sent, e.g., over 
a wireless network, ultimately for submission to an application server in the data center. 
The application server processes lottery game transactions to provide lottery games to 
remote terminals. Once the request is submitted, in Fig. 1b, the application server, 
using the reverse process, may return a requested lottery game toward the remote 
terminal. The requested lottery game may be, for example, an electronic representation 
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of a lottery ticket and/or a lottery entry confirmation. The described process may be 
used for all data transfer between the application server and the remote terminals. 

[012] In an embodiment of the present invention, players may purchase lottery 

tickets for a future drawing. In Fig. 1a, players purchase tickets, in 1 , e.g., by inputting 
requests for tickets into their cellular telephones, or any other wireless network remote 
terminals. In 100, the remote terminal may export data, e.g., the requests, security 
information, player or account code information, etc. The data may originate in 100, for 
example, as a Java transaction object. In 1 10-120, the requests may be converted into 
SMS text messages. At 125, the requests may be transmitted, e.g., over the wireless 
network towards the game-providerDs data center. The requests may be submitted to 
the data center in 130. In 135, multiple requests, for example from many players using 
many remote terminals, may be aggregated and routed to, for example, particular 
application servers. After the data center receives the SMS text messages, in 140-150, 
the SMS text messages may be converted to, for example, Java transaction objects. In 
160, an application server may receive the Java transaction objects and decipher them 
as lottery game requests. The application server may then, for example, retrieve the 
correct games (i.e. the tickets for the requested drawing). In Fig. 1 b, the application 
server may export data, e.g., the games, in 101. The data may originate as Java 
transaction objects, for example. In 1 1 1-121 , the data may be converted into 
corresponding SMS text messages. In 136, multiple messages, for example from a 
number of application servers, may be aggregated and routed, for example to a number 
of remote terminals. In 131 , the data may be exported from the data center. In 

126, the SMS text messages may be transmitted over the wireless network toward the 
requesting remote terminals. To complete the process, in 141-151, the SMS text 
messages may be converted into, for example, Java transaction objects. In 161 , the 
messages, already converted into Java transaction objects, may imported into the 
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remote terminals, for example to, display the games on the remote terminals* user 
interface display. Alternatively, the games may be displayed by any other data output 
means, such as a printout. Alternatively, the games may also be stored for future play, 
e.g., as an animated graphical game which may be displayed on a user's cell phone. 

[013] According to an embodiment of the present invention, messages, whether 

those in the form of requests or other data sent by the remote terminals toward the data 
center, or those in the form of games or other data sent by the data center toward the 
remote terminals, originate as Java transaction objects and are converted to SMS text 
messages for transmission over the wireless network. A number of translators may be 
employed to implement this conversion. More particularly, three translators may be 
employed. 

[014] In Fig. 1a, when transmitted from the remote terminal toward the 

application server, the data may originate, in 100, as a Java transaction object and may 
undergo a series of conversions before transmittal, in 125, over the wireless network. In 
110, translators may convert the message first from a Java transaction object to a 
binary message, then, in 1 15, to an ASCII text message, and finally, in 120, to an SMS 
text message. Once in an SMS text message format, in 125, the message may be sent 
over the wireless network toward its intended destination, e.g., the application server. 
Once sent over the wireless network, the reverse process may take place in 140, 145, 
and 150, wherein the message is reconverted to a Java transaction object for use at the 
intended destination, i.e. the application server. 

[015] Similarly, in Fig. 1b, data may be transmitted from the application server 

toward the remote terminal. In 101 , the data may originate, e.g., as a Java transaction 
object. The data may undergo a series of conversions. In 1 1 1 , translators may convert 
the message first from a Java transaction object to a binary message, then, in 1 16, to 
an ASCII text message, and finally, in 121, to an SMS text message. In 126, the 
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converted data may be transmitted over the wireless network. The data may be sent as 
an SMS message over the wireless network toward its intended destination, e.g., the 
remote terminal. Once sent over the wireless network, the reverse process may take 
place in 141, 146, and 151, wherein the message is reconverted to a Java transaction 
object for use at the intended destination, e.g., the remote terminal. 

[016] Consequently, two sets of translators (e.g., 6 translators total) may be 

provided, one set for messages transmitted between the wireless network and the 
remote terminals, and a second set for messages transmitted between the wireless 
network and the data center. The remote terminals and the data center may each 
contain their own set of translators, or external translators may be provided to perform 
the necessary translations. 

[017] Various communication protocols may be employed for transmitting game 

data between a remote terminal and an application server. Similarly, various 
messaging protocols, by which a translator translates game data between a Java 
transaction object and an SMS text message, may be employed. The discussed 
embodiment that employs a messaging protocol, whereby translators translate between 
a Java transaction object and a binary message, between a binary message and an 
ASCII text message, and between an ASCII text message and an SMS text message, is 
only one example protocol. Those skilled in the art can appreciate that other 
translators, that employ other messaging protocols for converting game data between a 
Java transaction object and an SMS text message, may be employed. 

[018] The above-described data transmission process may be repeated 

numerous times depending on the type of games the players play. For example, 
players may request quick pick tickets, wherein the game provider pre-selects the 
lottery ticket numbers, in which case after receiving the lottery games, the players need 
not send new data to the data center. Alternatively, players may choose to manually 
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pick the lottery ticket numbers. In this instance, in Fig. 1a, the players may input their 
lottery ticket numbers into their remote terminals, in 1 , and the inputted numbers may be 
transmitted toward the data center, in 125-130, as SMS text messages. Subsequent to 
the lottery drawing, the data center may transmit toward the remote terminals follow-up 
win-loss notices, SMS text messages that indicate to the remote terminals whether the 
players have won or lost the lottery games. The winnings may vary according to 
drawing. For example, one lottery-drawing's grand prize may be one million dollars, 
while another lottery-drawing's grand prize may be two hundred thousand dollars. Each 
drawing may have a number of win levels, for example, a grand prize of one million 
dollars and a second prize of two hundred thousand dollars. The follow-up win-loss 
notices may indicate a win type, e.g., grand prize winner or second prize winner, and it 
may indicate a win amount, e.g., one million dollars or two hundred thousand dollars. 

[019] In an alternative embodiment, the remote terminals may locally store the 

inputted numbers, wait for SMS text messages from the data center indicating the 
winning numbers, match the winning numbers, and if the two number sets match, 
transmit SMS text messages toward the data center indicating a win. The remote 
terminals may also indicate the type of win, e.g., grand prize or second prize. 

[020] In an alternative embodiment of the present invention, players may play 

lottery games having highly enriched graphics. The highly enriched graphics games 
may take the form of interactive games that give the players the illusion that they are 
playing games of skill. However, even these games may be games of chance, the 
game outcome independent of player skill. These games may depend on a future 
event. Alternatively, the data center may encode the transmitted lottery games with 
predetermined outcomes. The players are not initially made aware of the 
predetermined outcomes. Once the games are played, the players learn of their games' 
outcomes. The outcomes may be based on an algorithm that randomly assigns winning 
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and losing outcomes. In contrast with the embodiment involving lottery tickets, in this 
embodiment, players are not credited with a win until the players actively play their 
games and win. 

[021] In an alternative embodiment, the games may take the form of instant win 

games. For example, a scratch-off lottery game, wherein a card has a number of 
concealed game results, may be simulated on a display. The players learn the game's 
outcome by uncovering the concealed predetermined lottery game results. The 
outcome may be based on an algorithm that randomly assigns winning and losing 
outcomes. Players may be credited with a win after the players actively play their 
games and win. 

[022] After the data intended for the application server is sent, in 125, over the 

wireless network, an aggregator may, in 135, collect the data, identify the requesting 
terminal from which the data was sent, and, if more than one application server is 
provided, route the message to the corresponding application server. Similarly, in Fig. 
1 b, before sending the message from the application server over the wireless network, 
the aggregator may, in 136, route the message to the intended requesting terminal. 

[023] Fig. 2 is a block diagram that illustrates an example embodiment of the 

physical architecture of the present invention. The diagram illustrates the components 
of an example wireless network. A player may input data into cell phone 200. The input 
data or other cell phone game data may be converted by translators 202, shown here 
by way of example as external to cell phone 200, into SMS text messages. The SMS 
text messages may be sent via wireless network 205 toward data center 210. 
Translators 207, shown here by way of example as external to data center 210, may 
translate the SMS text messages into, for example, Java transaction objects. Within 
data center 210, aggregator 215 may be provided to collect cell phone game data of 
numerous cell phones and route the data to an appropriate application server 235. 
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Additionally, aggregator 215 may route application server data to the correct cell phones 
200. To implement routing of data to an appropriate application server 235, routers 220 
may be provided. A single or multiple firewalls 225 may be provided to protect 
application server 235 from corrupt data. Switches 230 may be provided to facilitate 
input to and output from application server 235. 

[024] Data center 210 may facilitate the play of many different types of games. 

Therefore, data center 210 may provide for many application servers 235, wherein each 
application server 235 contains and provides only some of the lottery games provided 
by data center 210. 

[025] Since many players may each request a single or multiple games, 

aggregator 215 may be provided. The aggregator 215 may be configured to collect 
each of the game requests (or other terminal data), route each request to the 
corresponding application server 235, receive the SMS text message representing the 
game (or other game data), and route it to the corresponding cell phone 200. 
Aggregator 215 may be provided within data center 210. Alternatively, external 
aggregators may be provided. 

[026] According to an embodiment of the present invention, data center 210 

may keep an account for each lottery game player or, alternatively, for each cell phone 
200. Alternatively, a separate entity for account holding may be provided, wherein data 
center 210 and the separate entity are communicatively in contact. Any number of 
schematics may be employed with numerous entities in contact with each other to 
facilitate the use of the present invention. 

[027] To record debits and credits of a playerOs account, application server 235 

may be connected to account records 240. When a player purchases a lottery game, 
application server 235 may indicate the purchase to account records 240 to record a 
debit. When a player wins a lottery game, application server 235 may indicate the win 
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to account records 240 to record a credit. In an alternative embodiment, aggregator 
215 may directly route account records data to account records 240 to process a credit 
or a debit, bypassing application server 235. The amounts debited and credited may 
vary depending upon the games the players play. 

[028] In an embodiment of the present invention, as illustrated in Fig. 2, data 

center 210 may be in contact with a playerOs bank 245, or other financial entity, for 
funds transfers according to a playerOs account in account records 240. Funds 
transfers may take place at predetermined time intervals, such as weekly, monthly, etc. 
Alternatively, funds transfers may take place transactional^, wherein, for example, 
funds are transferred from the playerOs bank 245 immediately upon a lottery game 
purchase. 

[029] Fig. 3 is a flowchart that illustrates an example procedure in which many 

players who use individual cell phones 200 may contact one another to collaboratively 
play a lottery game, according to an embodiment of the present invention. By way of 
example, the flowchart illustrates this procedure with respect to a lottery drawing game. 

[030] In 300, players enter input into their cell phones indicating a desire for 

collaborative play. In 305, one or all of the collaborating cell phones 200 may request 
from data center 210, via an SMS text message, the purchase of the lottery drawing 
game and may indicate the cell phones 200 contributing to the lottery game. Each cell 
phone 200 may contribute to the game equally or with varying percentages. In 310, the 
extent of the contribution of each cell phone 200 may be indicated to data center 210. 
Alternatively, a player chosen share distribution may be indicated. Alternatively, an 
indication of collaboration may be indicated, so that debits and credits are equally 
distributed among the participating cell phones' accounts. These indications of 
collaboration, contribution percentages, and/or share allocations may be transmitted 
toward data center 210 when the game is purchased. In an alternative embodiment, the 
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indications may be transmitted subsequent to game play. 

[031] In 315, the lottery drawing may be conducted. In 320, data center 210, for 

example, may determine whether cell phones 200 won or lost. In 325, if cell phones 
200 lost, data center 210 may transmit a notice of loss toward cell phones 200. If cell 
phones 200 won, in 326, data center 210 may determine the win type and/or win 
amount. Then in 331, data center 210 may transmit a notice of win, win type, and/or 
win amount toward cell phones 200. 

[032] In accordance with computations in 330 and 336, respectively, account 

records 240 may allocate a portion of the debits and credits pertaining to the 
collaboratively purchased lottery game, in 335 and 341, respectively, to each of the 
contributing cell phones 200. The computations in 330 and 336, respectively, may be in 
accordance with the equal or varying contributing percentages. Alternatively, the 
collaborating players may indicate the percentages of each collaborating playerOs share 
in the debits and credits. The indicated percentages need not equate with the players 1 
contributing percentages. The amount allocated may be in accordance with the 
indicated percentages, rather than the contributing percentages. 

[033] In 345, each cell phone 200's balance may be computed based upon each 

cell phone 200's debits and credits. At some point in time, in 350, funds transfers 
between each cell phone 200's bank and application server 210 may be implemented, 
based upon each cell phone 200's balance. 

[034] Data center 210 may itself provide the cell phones 200 with messaging 

capabilities to transmit messages over the wireless network. Alternatively, data center 
210 may collaboratively coordinate its functionalities with those of one or many cellular- 
telephone-providers' functionalities, for example, to provide the cell phones 200 with the 
messaging capabilities. Any of numerous implementations of physical network 
architectures as known in the art may be employed. Numerous networks, each with 
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various assigned functions may be interconnected to achieve the described system or 
method. Data center 210 may employ a number of aggregators, routers, firewalls, 
switches, and application servers. Alternatively, some of these components may be 
externally provided. Any communication protocol as known in the art, such as GPRS, 
SMSC, TCP/IP and RMI, may be used to transmit data within the network. 

[035] Those skilled in the art can appreciate from the foregoing description that 

the present invention can be implemented in a variety of forms. Therefore, while the 
embodiments of this invention have been described in connection with particular 
examples thereof, the true scope of the embodiments of the invention should not be so 
limited since other modifications will become apparent to the skilled practitioner upon a 
study of the drawings, specification, and following claims. 
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